In recent years, traditional circuit-based communication networks have declined in favor of packet-based networks, which can be more flexible, efficient, and secure. As a result, the increased popularity of packet-based networking has led to growth in demand for packet-based network devices. This demand has largely been met by manufacturers, who have created larger and larger monolithic routers to handle the increased volume and complexity of network traffic. However, this model is approaching its technologic and economic limits. It is now increasingly difficult to fulfill increasing performance requirements with traditional router designs, and, with the emergence of low cost data center hardware, router vendors have difficulty justifying the higher costs of hardware for the same performance. At the same time, the demands on the routing and switching control plane in access and aggregation networks are becoming more complex. Operators desire the ability to customize routing to handle specific types of traffic flows near the edge, configure customized services that span aggregation networks, and achieve multi-layer integration, without the detailed low-level configuration required in today's networks.
These trends led to a different approach to network architectures in which the traditional data and control planes have been decoupled. With this separation, the control plane may be logically centralized and implemented with commercial off-the-shelf (COTS) hardware. Further, the data plane may consist of simplified switch/router devices configured by the logically centralized controller. This new model focuses on the split of control from forwarding and data processing elements and is at the core of software-defined networking (SDN). One prominent standard for flow processing in software-defined networks is OpenFlow, which defines a protocol used to transport messages between the control plane and the forwarding plane and describes a model for packet processing.
This split responsibility present in software-defined networks enables a separation between functionalities that can be logically or physically grouped together. For example, there can be a split or separation between a common control entity and a network application (e.g., Generalized Multi-Protocol Label Switching (GMPLS), Border Gateway Protocol (BGP), Internet Protocol Security (IPSec), etc.). Similarly, there can be a split or separation between control and forwarding/processing (i.e. a separation of central control from network devices performing packet processing). There also can be a split or separation of a data forwarding functionality, a data processing functionality, and a data generation functionality (e.g., Deep Packet Inspection (DPI); Ciphering; Operations, Administration and Management (OAM)).
Software-defined networks present many advantages over traditional monolithic architecture networks. For example, in SDNs the control plane applications that implement important network routing and switching functionalities are completely separated from the forwarding plane. Thus, the centralized control planes of SDNs enable highly customized and optimized networking services that can be tailored to specific user needs, and can provide a highly scalable, reliable, and flexible networking infrastructure. Further, the forwarding plane network devices can be inexpensive and interchangeable commodity networking devices, which reduces the overall configuration and maintenance burdens for the user. Additionally, the use of a single management and configuration entity for the entire network enhances the ease-of-use experience for users.
However, since the network elements (i.e. forwarding elements) of the forwarding plane will not generally know what sort of forwarding behavior the controller will request, they must support a wide variety of valid behaviors according to the relevant SDN protocol(s) in use.
Forwarding planes on high-speed networking switches and routers are generally implemented in hardware with varying flexibility. Some of the fastest networking devices will use forwarding Application Specific Integrated Circuits (ASICs) designed for specific behaviors such as basic Ethernet bridging, or basic Internet Protocol (IP) routing. Another class of network devices will use Network Processors (NP) to improve programmability and flexibility at the cost of some forwarding performance. Yet another class of networking device will use more general-purpose processors in the datapath, which allows for tremendous flexibility but at the expense of the slowest performance. In all these three models, forwarding is generally table-driven, with forwarding behavior determined by one or more lookups in some sort of lookup table, using packets header field values such as Media Access Control (MAC) addresses or IP addresses as keys or parts of keys.
Although NPs are flexible and programmable, current devices are not designed with enough flexibility to accommodate a typical SDN protocol such as OpenFlow. Thus, the implementation of the OpenFlow protocol on a Network Processor is possible but presents challenges that will vary depending on the specific NP.
One major challenge is how to support table lookups when the types of tables are not defined in advance and when the types of tables may change over time. A typical router implementation built on an NP might define a table structure to extract the packet's destination IP address (“Dest-IP”) and use that as a key to a route table. However, a typical SDN application might prefer to define a table that uses the Dest-IP and also the Destination Transmission Control Protocol (TCP) port (“Dest-TCP-port”) as the key, but the definition of this table is not known while building the SDN-capable network node. Further, in the OpenFlow protocol, for example, there are approximately 40 defined match fields that must be supported by a forwarding element, as the OpenFlow controller can define a table—during runtime—using any combination of these fields.
Accordingly, it would desirable to have the ability, in a network element, to incorporate the performance benefits of ASIC-based or NP-based forwarding elements (which are often unable to support the runtime creation of tables using flexible keys) along with the flexibility of general-purpose processor based forwarding elements (which often have poor performance) to support software-defined networking.